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ABSTRACT 


This  research  examines  the  Naval  Reserve  organization, 
information  systems  (IS)  planning,  and  IBM's  Business 
Systems  Planning  (BSP)  methodology.  The  Naval  Reserve  is 
analyzed  in  the  context  of  IS  planning  requirements.  The 
information  needs  of  the  organization  are  examined  as  well 
as  that  organization's  current  IS  planning  process.  BSP  is 
investigated  as  an  alternate  planning  methodology.  A 
partial  analysis  of  the  Naval  Reserve  using  BSP  is  used  as 
an  illustration  of  the  methodology.  It  highlights  some  of 
t..e  information  related  complexities  and  organizational 
influences  that  confront  the  IS  planner. 
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I.  INTRODUCTION 


Information  is  a  key  resource  in  any  organization.  The 
Naval  Reserve  is  no  exception.  But  is  it  treated  as  a  key 
resource?  How  is  it  managed?  Clearly,  the  management  of 
information  within  the  Naval  Reserve  is  dependent  upon  the 
larger  issues  of  strategic  policy  and  organizational 
philosophy  regarding  information  systems  management.  It  is 
not  a  question  of  whether  the  Naval  Reserve  should  plan  the 
evolution  of  their  information  architecture,  because  some 
kind  of  planning  is  taking  place,  mandated  at  least  by  the 
budgeting  process.  The  question  is  how  well  articulated  is 
that  planning  process  and  what  is  the  methodology  behind  it? 
IBM's  Business  Systems  Planning  (BSP)  is  one  such 
methodology.  Would  it  be  an  ^appropriate  information  systems 
planning  guide  for  the  Naval  Reserve?  The  purpose  of  this 
thesis  is  to  evaluate  BSP  as  a  methodology  for  analyzing  the 
Naval  Reserve  in  order  to  determine  information  systems  (IS) 
needs . 

This  thesis  is  limited  to  an  evaluation  of  BSP  as  a 
methodology  for  understanding  information  flow  in  the  Naval 
Reserve  in  order  to  enable  information  resource  decisions  to 
be  made  in  a  coherent  and  consistent  manner.  To  adequately 
evaluate  this  methodology  it  is  necessary  to  examine  the 
entire  Naval  Reserve  structure.  This  organization  will  be 
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examined  by  itself  and  as  a  part  of  the  larger  Navy 
organization . 

This  thesis  attempts  to  answer  the  following  questions: 

1)  What  is  the  structure  of  the  Naval  Reserve  and  what  is 
the  information  flow  that  supports  that  structure? 

2)  What  are  the  current  information  systems  supporting 
the  Naval  Reserve  and  how  effective  are  they? 

3)  Does  the  Naval  Reserve  have  a  long-range  IS  strategy, 
and  if  so,  what  is  the  methodology  behind  it? 

4)  Is  BSP  a  feasible  approach  for  IS  planning  in  the 
Naval  Reserve? 

Chapter  II  examines  the  structure  of  the  Naval  Reserve 
organization.  The  context  of  that  examination  is  in  the 
supporting  information  flows,  both  internal  and  external. 
The  information  systems  of  the  organization  are  also 
evaluated  in  this  chapter.  The  purpose  of  Chapter  II  is  to 
familiarize  the  reader  with  the  organization  and  its  func¬ 
tions  in  a  general  way  and  to  gain  an  appreciation  for  some 
of  the  complexities  facing  the  IS  planner. 

Chapter  III  looks  at  some  of  the  issues  involved  in 
strategic  IS  planning.  BSP  is  introduced  here  in  relation 
to  other  planning  methodologies.  Finally,  this  chapter 
examines  the  IS  planning  process  of  the  Naval  Reserve. 

Chapter  IV  examines  the  BSP  methodology  in  more  detail. 
This  is  done  in  the  context  of  the  Naval  Reserve.  A  partial 
analysis  of  the  organization  is  undertaken  utilizing  the  BSP 
methodology . 
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II.  A  DESCRIPTION  OF  THE  NAVAL  RESERVE  ORGANIZATION 

A.  INTRODUCTION 

There  are  two  main  objectives  for  this  chapter: 

1)  To  describe  the  organizational  structure  of  the  Naval 
Reserve  and  the  interfaces  it  has  with  other  commands. 
The  focus  of  this  discussion  will  be  on  the  internal 
and  external  information  flows. 

2)  To  present  a  description  of  the  automated  information 
systems  in  place  within  the  organization  and  an 
evaluation  of  the  extent  to  which  they  appear  to 
satisfy  the  functional  needs  of  the  organization. 

The  structural  relationships  are  represented  by  five 
diagrams  (Figures  2-1  through  2-5)  .  Figure  2-1  shows  the 
internal  hierarchical  structure  of  the  Naval  Reserve. 
Figures  2-2 (  2-3,  and  2-4  are  the  organization  diagrams  for 

the  staffs  of  Commander  Naval  Reserve  Force  (CNRF) , 
Commander  Naval  Air  Reserve  Force  ( CNARF) ,  and  Commander 
Naval  Surface  Reserve  Force  (CNSRF)  respectively.  Although 
they  may  be  great  fun  to  look  at,  the  utility  of  organiza¬ 
tional  charts  in  describing  what  is  happening  within  an 
organization  and  the  relative  power  of  each  box  is  dubious 
at  best.  They  do  little  to  describe  the  political  reality 
of  the  organization .  The  most  important  part  of  any  organi¬ 
zation  is  what  nappens  between  the  blocks,  the  mechanisms 
for  communication  and  conflict  resolution.  This  same  caveat 
applies  to  the  fifth  diagram  (Figure  2-5).  It  depicts  the 


interfaces  between  the  Naval  Reserve  and  various  outside 


COMMANDER  NAVAL  RESERVE  FORC 


Naval  Air  Reserve  Staff  Command  Structure 


Figure 


commands.  It  is  not  as  clean  as  the  other  diagrams  because 
there  exist  external  interfaces  at  various  internal  organi¬ 
zational  levels. 

The  following  discussion  will  focus  primarily  on  the 
information  flows  represented  by  the  arrows  in  Figures  2-1 
and  2-5.  As  can  be  readily  seen,  to  describe  the  Naval 
Reserve  organization  and  its  supporting  information  flows, 
even  in  a  general  way,  is  no  simple  task,  due  principally  to 
the  complexity  of  the  external  interfaces.  This  discussion 
will  concentrate  on  the  manpower,  personnel,  and  training 
functions  of  the  Naval  Reserve.  The  areas  of  logistics  and 
facilities  management  will  not  be  examined.  This  is  not 
because  they  are  not  important,  but  to  keep  the  analysis 
from  becoming  too  burdensome;  and  because  they  can  be  broken 
out  fairly  cleanly,  that  is,  their  processes  and  information 
flows  are  separate  and  distinct  from  the  areas  under 
consideration  here. 

B.  THE  INTERNAL  ORGANIZATIONAL  STRUCTURE 

The  mission  of  the  Commander  of  the  Naval  Reserve  is  the 
training  and  administration  of  all  Naval  Reserve  forces. 
The  Naval  Reserve  Command  manages  and  administers  over 
120,000  personnel;  3000  drilling  units  at  over  300  drill 
sites;  assets  in  excess  of  four  billion  dollars;  and  annual 
expenditures  in  excess  of  900  million  dollars.  With 
resources  such  as  these,  it  is  imperative  that  information 
concerning  personnel,  money,  equipment,  and  most 


importantly,  the  relationship  of  these  factors  to  overall 
readiness  be  accurate  and  readily  available.  The  overall 
goal  of  automated  information  systems  within  the  Naval 
Reserve  should  be  to  support  efficient  and  effective 
resource  management,  track  training  and  personnel  mobiliza¬ 
tion  readiness,  and  provide  an  efficacious  mechanism  for  the 
support  of  mobilization.  The  rest  of  this  chapter  will 
explore  the  functions  of  the  different  command  levels,  the 
scope  and  source  of  the  information  necessary  to  effectively 
perform  those  functions,  and  the  role  of  existing  automated 
information  systems  in  support  of  that  performance. 

The  concentration  here  will  be  on  those  functions  which 
are  essential  for  accomplishing  the  mission  area  objectives 
of  the  Naval  Reserve.  Although  none  of  these  functions  is 
wholly  confined  to  any  one  level  of  the  organizational 
hierarchy,  the  degree  and  requisite  information  at  each  com¬ 
mand  level  should  be  different  for  each  function.  The  major 
manpower,  personnel,  and  training  (MPT)  functions  of  the 
Naval  Reserve  are:  1)  reserve  pay  and  personnel;  2)  man¬ 
power  management;  3)  mobilization;  4)  training;  and  5) 
recruiting . 1 


-’-As  will  be  discussed  in  the  next  chapter,  OP-094  is 
responsible  for  developing  the  Navy's  high  level  information 
architecture;  and  the  Director,  Total  Force  Information  Sys¬ 
tems  Management  Division  (OP-16)  is  responsible  for  develop¬ 
ing  the  information  architecture  for  MPT  functions.  All  of 
the  functional  sub-areas  identified  by  OP-16  are  not  pre¬ 
sented  here.  The  additional  five  functional  areas  were 
intentionally  omitted  because  they  are  felt  to  apply  only 
peripherally  or  as  part  of  a  broader  functional  area.  The 


A  decomposition  of  functional  processes  and  their 
related  input/output  data  reveals  seven  major  categories  of 
information  required  to  support  the  MPT  functional 
processes.  These  categories  of  information,  their  defini¬ 
tions,  as  well  as  a  discussion  of  the  source  and  extent  (at 
what  command  levels  the  information  is  needed)  of  that 
information  follow: 

a)  MANPOWER — Information  related  to  billet/position  re¬ 
quirements  (quality  and  quantity) ,  billet  authoriza¬ 
tions,  and  strength.  The  source  of  this  information 
is  outside  the  Naval  Reserve  organization  at  the  OPNAV 
level.  The  preponderance  of  this  information  is 
needed  at  the  upper  command  levels  for  planning  and 
program  management.  The  individual  unit  C.O.  has  need 
for  this  information  only  as  it  applies  to  his  unit. 

b)  PERSONNEL — Personal  information  needed  to  train,  mobi¬ 
lize,  promote,  assign,  retain/separate  individuals. 
This  information  originates  at  the  Reserve  unit  level. 
The  need  for  this  data  in  anything  other  than  summary 
format  above  the  echelon  4  level  is  questionable. 

c)  PAY — Information  relating  to  the  expenditure  of  funds 
from  the  RPN  appropriation.  The  source  of  the  expen¬ 
diture  data  is  the  Naval  Finance  Center  (NAVFINCEN) 
and  it  is  used  in  varying  degrees  by  all  command 
levels.  The  individual  reservist  is  concerned  with 
his  paycheck,  the  comptrollers  their  budget,  and  the 
Personnel  Support  Detachments  (PSD)  their  disburse¬ 
ments.  The  source  of  the  data  from  which  the  expendi¬ 
tures  are  derived  is  at  the  echelon  5  level,  the  unit 
and  Reserve  Center.  Any  area  where  real  money  is 
involved  is  a  sensitive  one.  The  accountability 
measures  and  potential  for  fraud  have  thus  far  pre¬ 
cluded  this  process  (at  the  unit  level)  from 
automation. 

d)  TRAINING — Information  needed  to  plan  and  manage  train¬ 
ing,  including  evaluation  of  selected  reserve  (SELRES) 
readiness.  This  information  originates  at  both  ends 
of  the  spectrum.  The  requirements  are  defined  at  the 
program  sponsor  (OPNAV)  level  and  refined  at  the 


interested  reader  can  refer  to  Reference  1. 


echelon  2,  3,  and  4  levels.  Readiness  is  evaluated  at 
the  unit  level  and  flows  in  a  condensed  and  summarized 
format  back  up  the  chain  and  to  gaining  commands  out¬ 
side  of  the  Naval  Reserve  organization. 

e)  MOBILIZATION — Recall  and  status  information  required 
to  mobilize  the  total  force.  Again  this  is  informa¬ 
tion  that  originates  at  both  ends  of  the  spectrum. 
The  critical  issue  here  is  not  so  much  the  information 
but  the  communication  of  that  information.  Present 
mobilization  procedures  utilize  a  poor  mix  of  old  and 
new  technologies. 

f)  POLICY — Higher  level  guidance  which  ensures  business 
is  conducted  in  a  consistent  manner.  Military  policy 
usually  is  dictated  from  above  and  flows  downhill,  but 
information  from  which  those  policies  are  derived 
comes  from  many  different  sources. 

g)  PPBS — Information  relating  to  POM  and  budgeting  proc¬ 
ess.  Ideally  this  information  originates  at  the  low¬ 
est  command  levels  and  moves  upward  in  a  summary 
format.  Generally  the  level  of  detail  is  greater  at 
the  lower  levels  for  any  individual  line  item  while 
the  breadth  of  information  is  greater  at  higher 
command  levels. 

The  idea  of  the  varying  extent  of  each  of  these 
categories  at  different  command  levels  is  presented 
graphically  in  Figure  2-6. 

No  analysis  of  the  internal  organizational  structure  is 
complete  without  an  obligatory  reference  to  the  staff  wiring 
diagrams  (Figs.  2-2,  2-3,  and  2-4).  As  was  mentioned  at  the 
beginning  of  this  chapter,  the  diagrams  are  of  limited  value 
because  they  often  do  not  accurately  describe  the  organiza¬ 
tion.  Nevertheless  they  do  draw  attention  to  a  few  inter¬ 
esting  relationships.  One  is  what  they  say  about  the 
relative  importance  of  the  MIS  function  within  the  organiza¬ 
tion.  There  is  no  formally  identified  focal  point  on  the 
Air  or  Surface  staffs  for  MIS  matters;  and  that  function  on 


the  CNRF  staff  is  low  in  the  hierarchy  and  separate  from 
other  functional  areas.  It  is,  however,  formally  in  the 
planning  department  and  supposedly  responsible  for  ADP 
planning.  Although  these  are  officially  three  separate 
staffs,  they  are  physically  located  in  the  same  building. 
They  are  not  as  separate  and  distinct  as  the  organization 
charts  would  seem  to  suggest.  The  senior  flag,  Air  or 
Surface,  also  serves  as  Commander  Naval  Reserve  Force. 
These  are  important  distinctions  to  remember  when  looking  at 
how  information  systems  planning  is  oeing  done  and  who  is 
doing  it. 

C.  EXTERNAL  INFORMATION  INTERFACES 

One  useful  way  of  looking  at  the  information  require¬ 
ments  of  the  Naval  Reserve  is  to  view  that  information  as  a 
total  force  requirement  in  relation  to  the  individual  reser¬ 
vist.  That  individual  reservist  can  then  be  perceived  as 
both  the  raw  material  and  the  finished  product  of  the  Naval 
Reserve  subsystem. 

The  functions  of  the  users  of  the  different  categories 
of  MPT  information  can  be  placed  in  one  of  three  broad 
classes:  planning,  control,  or  execution.  These  are  analo¬ 
gous  to  the  functions  of  top  (strategic),  middle,  and  line 
(operations)  management  in  the  business  environment.  The 
characteristics  of  the  requisite  information  resources  is 
different  for  each  of  these  processes.  Information  required 
for  operational  control  functions  will  generally  need  to  be 


more  accurate,  structured,  detailed,  and  timely  than 
information  used  for  strategic  planning  purposes.  The  Naval 
Reserve  and  the  interfacing  external  commands  can  therefore 
be  looked  at  as  being  concerned  with  the  individual  reser¬ 
vist  in  either  a  strategic  planning  role,  program  control 
role,  or  program  execution  role. 

The  primary  organizations  that  are  responsible  under  the 
total  force  management  concept,  for  the  participating  reser¬ 
vist  are:  for  planning--OP-01  and  OP-09R;  for  control--CNRF 
(echelons  2  through  4)  ,  Naval  Military  Personnel  Command 
(NMPC) ,  Naval  Reserve  Personnel  Command  (NRPC) ,  and 
NAVFINCEN;  for  execution — CNRF  (all  echelons)  and  PSDs. 
This  is  by  no  means  a  complete  list.  Other  interfacing 
organizational  entities  include:  Congress,  Office  of  the 
Secretary  of  Defense  (OSD) ,  Joint  Chiefs  of  Staff  (JCS) , 
resource  sponsors,  Navy  Comptroller  (NAVCOMPT) ,  Chief  of 
Naval  Education  and  Training  (CNET) ,  Commander  Navy  Recruit¬ 
ing  Command  (CNRC) ,  and  World-Wide  Military  Command  and 
Control  System  (WWMCCS) . 

The  general  way  in  which  the  sources  or  end  users  of 
different  categories  of  information  are  outside  the  scope  of 
the  Naval  Reserve  organization  has  been  described  in  the 
previous  section.  The  thrust  of  this  section  has  been  to 
describe  the  information  related  interfaces  between  the 
Naval  Reserve  and  external  organizations  in  a  less  parochial 
more  gestalt  manner.  This  discussion  has  focused  on  the 


relationships  depicted  in  Figure  2-5.  The  matrix  below 
relates  the  different  types  of  information  to  some  of  the 
external  commands  by  showing  what  categories  of  information 
go  beyond  the  Naval  Reserve  organization  and  the  other  com¬ 
mands'  that  are  involved. 

EXTERNAL  COMMANDS 


INFO 

CATEGORIES 

OPNAV 

NMPC 

NRPC 

NAV- 

FINCEN 

CNRC 

CNET 

WNMCCS 

PSA/ 

PSD 

MANPOWER 

X 

PERSONNEL 

X 

X 

X 

X 

X 

PAY 

X 

X 

X 

X 

X 

TRAINING 

X 

X 

X 

X 

X 

X 

MOB 

X 

X 

X 

X 

X 

POLICY 

X 

X 

PPBS 

X 

X 

X 

X 

The  purpose  of  examining  the  nature  and  extent  of  the 
external  information  interfaces  is  to  recognize  the  impact 
of  this  complex  network  of  data  interdependencies  on  infor¬ 
mation  systems  planning.  Much  of  the  data  are  owned  and/or 
defined  by  these  external  organizations.  Although  these 
definitions  should  be  consistent  across  different  commands, 
it  is  too  often  the  case  that  they  are  not.  The  problem  of 
data  administration  is  central  to  the  development  of  any 
coherent  information  architecture  in  the  MPT  arena.  Unfor¬ 
tunately  this  cannot  be  addressed  in  much  more  than  a 


reactionary  mode  at  the  CNRF  level  for  data  externally 
defined . 

D.  CURRENT  NAVAL  RESERVE  AUTOMATED  INFORMATION  SYSTEMS 

This  section  will  describe  the  automated  information 
systems  being  used  within  the  Naval  Reserve  organization  to 
support  those  functions  outlined  in  the  previous  sections. 
An  attempt  will  also  be  made  to  evaluate  the  effectiveness 
of  those  systems.  The  efficiency  of  those  systems  will  not 
be  considered  unless  it  was  designated  a  pivotal  critical 
success  factor  in  the  design  of  the  system;  or  if  an  effec¬ 
tive  system  is  plainly  inefficient.  The  reason  for  this 
focus  of  evaluation  is  that  it  is  very  easy  to  get 
sidetracked  in  efficiency  issues  while  losing  sight  of  the 
big  picture.  You  may  be  spending  all  your  time  evaluating 
the  speed  and  proficiency  of  the  ambulance  crews  in  the 
valley  when  you  should  be  asking  why  there  is  no  fence  on 
the  cliff. 

There  are  at  least  two  levels  of  analysis  of  the  effec¬ 
tiveness  of  an  AIS .  The  obvious  evaluation  is  to  determine 
if  it  is  accomplishing  the  function  (s)  for  which  it  was 
designed.  The  second,  sometimes  less  perceptible,  concern 
deals  with  the  legitimacy  of  the  design.  It  is  examining 
the  utility  of  the  function  in  light  of  the  organization's 
missions.  Should  the  function  be  performed?  If  so,  should 


it  be  automated? 


1 .  The  Reserve  Training  Support  System  CRTSS) 


The  Reserve  Training  Support  System  (RTSS)  is  an 
outgrowth  of,  and  essentially  the  same  as,  the  active  duty 
system  known  as  the  Aviation  Training  Support  System  (ATSS) . 
The  ATSS  concept  was  designed  in  1971  as  a  training  support 
system  oriented  toward  enlisted  aircraft  maintenance  train¬ 
ing,  and  was  developed  out  of  a  need  for  relief  in  assigning 
courses  and  tracking  students..  Its  early  success  led  to 
duplication  and  adaptation  by  other  communities.  The  Naval 
Air  community  currently  uses  ATSS.  The  Submarine  community 
uses  VTS .  The  Reserve  community  named  their  adaptation 
RTSS.  These  systems  all  have  the  same  basic  configuration. 

The  original  procurement  of  the  DEC  PDP  11/4  0  com¬ 
puter  as  the  initial  hardware  for  the  ATSS  system  in  1971 
was  exempted  from  the  lengthy  and  complex  Automatic  Data 
Processing  Equipment  ( ADPE)  approval  requirements  by  the 
Chief  of  Naval  Material  because  it  was  designated  solely  a 
training  device.  In  order  to  keep  the  designation  as  a 
training  device  certain  design  alternatives,  such  as 
expanding  the  system  to  include  requirements  for  other 
related  information  systems,  had  to  be  traded-off  as  the 
system  evolved.  The  decisions  not  to  expand  ATSS  were  based 
on  the  perceived  need  to  maintain  exemption  status  under  the 
ADPE  acquisition  regulations.  This  is  an  important  implica¬ 
tion  in  the  development  of  RTSS  inasmuch  as  it  was  fashioned 
after  the  model  of  ATSS. 
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The  Chief  of  Naval  Reserve  became  interested  in  ATSS 

as  a  viable  training  and  administration  tool  in  1977.  ATSS 

was  chosen  as  the  most  cost-effective  method  to  achieve  its 

required  personnel  training  and  training  management  support. 

One  justification  was  that  savings  would  be  realized  by 

adopting  an  existing  system  and  avoiding  the  time-consuming 

and  expensive  systems  development  process.  Many  of  the 

shortcomings  of  the  present  system  can  be  traced  back  to 

this  basic  fallacious  assumption.  For  funding  and  control 

purposes  the  system  was  renamed  the  Reserve  Training  Support 

System  (RTSS) .  It  consisted  of  three  major  component 

systems:  RTSS (TM)  for  training  management,  RTSS (Surface) 

for  surface/ashore,  and  the  RTSS (Air)  for  aviation.  This 

analysis  will  focus  primarily  on  the  Training  Management 

(TM)  and  Surface  components  of  RTSS.  CNAVRESINST  5230  [Ref. 

2:p.  2-1]  established  policy  for  the  development  as  follows: 

The  Reserve  Training  Support  System  (RTSS)  is  an  automated 
training  management  support  system.  The  purpose  of  the 
system  is  to  provide  training  management  support  to  field 
Naval  Reserve  training  administrators  and  to  increase  the 
quality  of  training  readiness  information  reporting  at  all 
Naval  Reserve  Command  levels.  A  dual  system  approach  will 
provide  for  a  field  training  system  in  support  of  Naval 
Reserve  field  administrators  and  a  Regional  Training 
Management  System  in  support  of  staff  functions. 

Another  subsystem  (RESULTS)  has  recently  been  added 
to  support  new  recruit  tracking.  The  RTSS (TM)  is  the  pri¬ 
mary  component  of  the  three  and  the  objectives  of  the  other 
components  are  mostly  subsets  and  elaborations  of  its  objec¬ 
tives.  The  RTSS (TM)  was  designed  to  support  training 


management,  mobilization  assignment,  readiness  measurement, 
and  mobilization  and  readiness  reporting.  The  long-term 
objectives  of  the  system  are  [Ref.  3:pp.  2-2, 2-3]: 

a)  Increasing  the  quantity  and  quality  of  Selected 
Reserve  mobilization  billet  assignment  capability  at 
all  command  levels. 

b)  Integrating  personnel  and  training  record  data  under  a 
single  system  accessible  from  remote  locations. 

c)  Providing  a  methodology  for  the  real-time  measurement 
and  reporting  of  personnel  training  readiness. 

d)  Increasing  the  efficiency  and  effectiveness  of 
scheduling  training  for  the  drilling  Reservist. 

e)  Providing  more  timely  and  accurate  information  for 
mobilization  reporting. 

f)  Improving  the  reliability  of  training  information  at 
all  command  levels. 

g)  Reducing  the  administrative  and  clerical  workload  of 
operating  units. 

h)  "Capturing"  input  data  at  the  source,  thereby  elimi¬ 
nating  intermediate  error-inducing  steps. 

i)  Providing  limited  stand-alone  local  processing  capabi¬ 
lities  for  the  Naval  Reserve  Center. 

j)  Providing  an  integrated  communications  capability 
enabling  the  localized  units  to  exchange/update  data 
with  CNAVRES  RTSS (TM)  centralized  data  base  and  other 
RTSS  (Surface)  units. 

When  the  system  was  first  conceived  the  long-term 
goal  was  for  the  three  components  to  be  fully  integrated 
into  a  consolidated  and  centralized  database  to  provide 
real-time  information  for  personnel,  mobilization,  recruit¬ 
ing,  readiness,  and  training  management.  At  present  they 
are  still  three  separate  systems  in  that  there  are  separate 
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duplicated  files  for  each  system.  The  Air  and  Surface  files 
are  updated  from  the  TM  on  a  periodic  basis. 

All  RTSS  hardware  is  obsolete  off-the-shelf  equip¬ 
ment  owned  and  maintained  by  CNRF .  The  RTSS (TM)  consists  of 
a  PDP-11  series  Central  Processing  Unit,  associated  periph¬ 
erals,  terminals,  interface  components,  and  communications 
equipment.  The  PDP-11  is  being  upgraded  to  a  DEC/VAX  780 
this  fiscal  year  which  will  require  redesign  of  the  operat¬ 
ing  system  and  database  management  system.  Communication 
between  the  central  computer  (New  Orleans)  and  remote  dumb 
terminals  (at  31  locations  throughout  the  U.S.)  is  accom¬ 
plished  through  asynchronous  modems  connected  to  a  dedicated 
line  via  local  call  access.  Three  nodes  share  one  line. 
The  RTSS  (Surface)  hardware  is  essentially  the  same,  there 
is  just  more  of  it.  Currently  there  are  17  PDP-11  series 
minicomputers  at  15  Regional  Readiness  Commands  and  two 
Central  Drill  Sites  (Central  Drill  Sites  are  essentially 
just  big  Reserve  Centers) .  The  goal  is  to  have  these  minis 
at  80  sites  throughout  the  country.  All  Reserve  Centers 
either  have  or  are  getting  microcomputers. 

The  RTSS  central  site  software  consists  of  the  DEC 
Resource  Sharing  Time  Sharing/Extended  (RSTS/E)  operating 
system,  several  Higher  Order  Languages,  applications  support 
programs,  and  applications  programs.  Software  is  centrally 
designed,  developed,  and  tested.  Programming  capabilities 


are  not  available  except  through  the  central  RTSS  site  in 
New  Orleans. 

The  majority  of  the  Data  Processing  personnel  are  in 
New  Orleans.  Each  Readiness  Command  (REDCOM)  has  one  DP 
trained  civilian  on  its  staff.  Any  additional  DP  skills  at 
command  levels  below  New  Orleans  (Echelon  2)  are  of  the 
home-grown  variety. 

The  principal  component-  of  RTSS  are  central  files 
kept  at  New  Orleans  with  remote  terminals  at  each  Readiness 
Command  and  Naval  Air  Reserve  sites  for  data  entry  and 
limited  file  queries.  The  route  which  data  follow  into 
those  files  is  circuitous  and  confusing.  The  process  begins 
at  the  Reserve  Unit  level  at  each  drill  site  (Reserve 
Center)  .  Each  drill  weekend  the  unit  must  complete  a  per¬ 
sonnel  diary  form  and  an  RTSS  input  form  to  record  any  per¬ 
sonnel  related  data  changes  (i.e.,  affiliations,  NOBCs, 
NECs,  mobilization  billet  readiness) .  This  information  is 
reviewed  for  accuracy  by  the  Reserve  Center  staff  and  the 
RTSS  form  is  mailed  to  the  cognizant  regional  Readiness 
Command;  the  diary  to  the  Naval  Reserve  Personnel  Center  New 
Orleans.  The  data  on  the  two  forms  should  be  identical. 
The  diary  information  is  input  to  the  Inactive  Manpower  And 
Personnel  Management  Information  System  (IMAPMIS)  database 
by  personnel  in  New  Orleans.  The  RTSS  information  is 
reviewed  at  the  REDCOM  and  input  to  the  RTSS  files.  Once  a 
month,  tapes  are  swapped  and  the  two  files  update  each  other 


(theoretically) ,  with  IMAPMIS  updating  all  the  fields  in 
RTSS  except  for  two,  Individual  Readiness  Assignment  Desig¬ 
nator  (IRAD)  and  Mobilization  Assignment  (MOBA) .  The 
IMAPMIS  files  are  updated  from  RTSS  for  these  two  fields. 
Although  this  crossover  is  supposed  to  be  taking  place 
monthly,  reports  generated  by  the  two  systems  infrequently 
coincide.  There  are  recognized  problems  in  the  IMAPMIS 
system  as  well  as  the  interface  between  the  two,  which  are 
being  worked  on. 

In  general,  RTSS  output  is  used  as  a  cross-check  on 
IMAPMIS  data,  but  the  latter  is  given  priority,  not  because 
IMAPMIS  produces  more  accurate  or  timely  data,  but  because 
it  is  the  recognized,  official  source  for  management  pur¬ 
poses,  including  pay  and  retirement  points.  In  fact,  RTSS 
is  perceived  as  the  more  accurate  source  of  information  but 
it  is  not  used  as  the  primary  management  tool  because 
IMAPMIS  is  the  official  source. 

The  current  distribution  of  data  processing  within 
the  RTSS  system,  using  Lorin's  [Ref.  4]  model,  finds  the 
system  components  slowly  spreading  outward,  the  DP  skills 
centralized,  and  the  management  centralized  by  design  but 
distributed  through  neglect.  In  the  words  of  a  special 
panel  which  looked  at  the  Information  Systems  requirements 
of  the  Naval  Reserve  in  1984,  "In  effect,  the  distribution 
of  computing  is  beginning  to  occur  without  a  plan,  and  with 
great  potential  for  duplication  and  ineffective  effort." 
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[Ref.  5:p.  5-2]  There  is  no  reason  to  assume  that  the 
situation  has  improved  in  the  two  years  since  that  study  was 
completed . 

How  well  does  the  present  system  satisfy  the  design 
objectives?  It  has  not  increased  the  quality  of  mobiliza¬ 
tion  billet  assignment  capability  at  all  command  levels,  and 
although  the  quantity  of  assignments  has  increased,  that 
growth  cannot  be  attributed  to  RTSS.  Since  IMAPMIS  is  still 
used  as  the  official  source  of  personnel  information,  the 
advantages  of  easier  access  to  the  RTSS  database  have  not 
been  realized.  Program  Managers  still  use  the  monthly 
IMAPMIS  reports  for  tracking  the  quality  of  mobilization 
billet  assignments. 

The  RTSS  has,  to  some  degree,  integrated  personnel 
and  training  record  data.  It  is  an  improvement  over  the 


previous  non-automated  system. 


Integration  problems, 


however,  still  exist.  This  data  is  definitely  not  accessi¬ 
ble  from  remote  locations  (Reserve  Centers) ,  and  its 
accessibility  from  the  REDCOM  level  is  constrained  by  the 
logistics  of  three  nodes  sharing  one  line  to  access  the 
central  database. 

It  has  not  provided  for  the  real  time  measurement 
and  reporting  of  personnel  training  readiness.  The  data  are 
not  input  to  the  files  at  the  source  (Reserve  Center)  ,  but 
instead  are  mailed  to  the  REDCOM  where  they  are  input.  The 
only  method  the  Reserve  Unit  Commanding  Officer  currently 


has  to  determine  the  file  contents  for  his  unit  is  by- 
referring  to  a  monthly  hardcopy  report  from  the  REDCOM. 


The  use  of  RTSS  has  provided  some  improvement  in  the 
area  of  mobilization  reporting,  although  it  is  still  far 
short  of  the  original  goals  for  this  area.  An  effective 
mobilization  process  is  the  cornerstone  of  a  viable  Reserve 
force  and  depends  on  a  reliable  communications  network  and 
sound  data.  The  problems  associated  with  this  area  in  the 
Naval  Reserve  are  still  considerable  and  the  current  RTSS 
architecture  does  little  to  resolve  them. 

The  RTSS  has  not  reduced  the  administrative  or 
clerical  workload  of  the  operating  units.  It  has  not 
provided  stand-alone  local  processing  capabilities  for  the 
Naval  Reserve  Center,  except  for  that  which  is  provided  by 
microcomputers,  which  are  not  part  of  the  RTSS. 

The  system  has  certainly  not  provided  an  integrated 
communications  capability  between  the  local  units  and  the 
central  database.  This  is  the  realm  in  which  the  RTSS 
offered  the  greatest  promise  and  has  produced  the  greatest 
disappointment.  Processors  are  being  distributed  with 
little  or  no  thought  being  given  to  communication.  Further¬ 
more,  this  is  just  internal  to  the  system.  There  are  a 
myriad  of  other  problems  associated  with  the  external  inter¬ 
faces,  such  as  the  IMAPMIS  discussed  earlier. 

Clearly,  the  current  RTSS  is  not  getting  the  job 
done.  It  does  not  provide  for  easy  information  retrieval  in 
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desired  formats.  It  contains  duplication  of  data,  with 
inconsistencies  in  definition  processing  and  data  entry 
which  has  lead  to  confusion  and  inaccurate  measures  of 
effectiveness.  The  present  system  was  developed  mostly 
during  a  period  when  available  hardware  and  software  were 
more  expensive  and  had  less  capability.  It  has  been 
developed  on  a  piecemeal  basis  in  response  to  particular 
needs  or  crises,  without  full  attention  to  possible 
duplication  or  potential  interfaces  and  interactions,  and 
often  without  adequate  design  participation  from  the  users. 
[Ref.  5 : p .  3-1] 

There  is  little  question  that  there  were  some 
serious  problems  with  the  planning  and  implementation  of  the 
RTSS.  In  the  words  of  one  of  the  contractors  who  developed 
the  system,  "It  was  developed  heuristically ,  like  a  police 
artist."  This  is  not  to  say  that  heuristic  design  is 
invalid,  but  that  heuristic  planning  is.  Actually  to  char¬ 
acterize  the  planning  of  the  RTSS  as  heuristic  implies  a 
discernible  methodology  which  the  evidence  indicates  was 
lacking.  The  manner  in  which  RTSS  has  been  planned  and 
implemented  can  best  be  presented  as  a  lesson  on  how  not  to 
design  an  automated  information  system. 

2 .  Reserve  Financial  Management/Act ive  Duty  For 

Training  System  (RESFMS) 

The  Reserve  Financial  Management/Active  Duty  for 
Training  System  (RESFMS)  is  the  other  major  automated  infor¬ 
mation  system  being  used  by  the  Naval  Reserve.  Its  purpose 
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is  to  provide  operational,  management,  and  planning  informa¬ 
tion  about  ACDUTRA  and  RPN  accounting  to  the  Commander, 
Naval  Reserve  Force. 

Before  the  RESFMS  system  was  developed,  the  Reserve 
personnel,  Navy  (RPN)  accounting  system  and  the  Active  Duty 
for  Training  (ACDUTRA)  order  writing  system  were  on  two 
separate  minicomputers.  Financial  accounting  data  generated 
in  the  ACDUTRA  system  regarding  commitments,  obligations, 
modifications,  and  cancellations  were  forwarded  to  the  RPN 
system  via  magnetic  tape.  Many  manual  procedures  still 
existed,  especially  in  the  financial  planning  and  program 
management  areas,  which  resulted  in  information  delays  and 
inaccuracies.  The  situation  continued  to  deteriorate  with 
increasing  ACDUTRA  expenditures  and  the  inability  of  the  two 
systems  to  keep  up.  In  1979  CNAVRES  overexpended  their 
allotted  funds,  a  serious  error.  RPN  accounting  was  over 
six  months  behind;  they  had  no  idea  what  their  current  RPN 
balance  or  expenditures  were.  This  crisis  led  to  the  formu¬ 
lation  of  plans  to  develop  a  more  comprehensive  and  respon¬ 
sive  ACDUTRA  and  RPN  accounting  system.  The  new  system, 
which  began  as  a  project  in  February  1981,  was  envisioned  as 
part  of  a  larger  effort  to  automate  several  aspects  of  the 
Naval  Reserve  operations  under  one  system.  Approximately 
two  and  a  half  years  later  the  initial  system  was  on-line. 
This  interactive  system  supports  the  ACDUTRA  operational 
functions  and  informational  needs  of  five  areas  at  CNRF 
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including  Manpower,  order  writing;  program  management  for 
Surface  and  Air  readiness;  the  passenger  transportation  sec¬ 
tion  of  the  Personnel  Support  Detachment  (PSD) ;  RPN  account¬ 
ing;  and  financial  management.  The  development  has  occurred 
in  two  phases.  Phase  I  addressed  ACDUTRA  order  writing, 
modification,  and  cancellation  at  CNRF  headquarters  includ¬ 
ing  processing  to  handle  the  estimation  and  obligation  of 
the  funding  for  executing  orders.  This  initial  system  was 
installed  on  the  NARDAC  UNIVAC  1100/60  in  New  Orleans  in 
March  1983.  The  still  on-going  phase  2  effort  has  as  its 
objective  the  extension  and  distribution  of  ACDUTRA  order 
writing  to  the  field  activities  in  the  Naval  Reserve. 

The  overall  goal  of  the  RESFMS  is  to  provide  CNRF 
with  a  comprehensive  system  for  the  management  and  control 
of  RPN  funds  and  to  provide  echelon  3  and  4  more  efficient 
management  of  the  Naval  Reserve  ACDUTRA  programs.  More 
effective  management,  in  this  case,  is  not  a  goal  because 
this  system  was  not  intended  to  conceptually  alter  the  man¬ 
ner  in  which  ACUDTRA  is  being  managed.  Its  purpose  is  to 
speed  up  the  process;  to  automate  time-consuming  manual 
procedures.  Some  of  the  more  specific  objectives  of  RESFMS 
are  [Ref.  6:pp.  2-1--2-1;  Ref.  7:pp.  2-2--2-4]: 

a)  Establish,  at  Echelon  III,  IV,  and  V  activities,  the 
capability  to  process  ACDUTRA  applications,  modifica¬ 
tions,  and  cancellations  by  means  of  an  automated 
information  system  (AIS). 

b)  Design  the  completed  ACDUTRA  System  so  that  it  func¬ 
tions  as  a  subsystem  of  the  Reserve  Financial  Manage¬ 
ment  System,  sharing  common  data  and  providing  the 


transfer  of  data  to  other  subsystems,  particularly  the 
RPN  Accounting  Subsystem. 

c)  Provide  on-line  access  to  those  users  whose  functions 
require  it,  allowing  them  to  access  and  input  source 
data  necessary  to  generate  ACDUTRA  orders  and  to 
schedule  system  programs  as  needed. 

d)  Provide  the  capability  to  edit  and  validate  all  user 
transactions  storing  them  for  problem  solving,  moni¬ 
toring,  or  auditing  needs. 

e)  Reduce  the  time  interval  between  ACDUTRA  application, 
return  of  the  resulting  order,  and  subsequent  RPN 
accounting  transaction  posting. 

f)  Provide  the  capability  to  track  and  monitor  the 
processing  of  an  ACDUTRA  application  through  final 
expenditure  or  cancellation. 

g)  Provide  the  capability  to  access  and  report  informa¬ 
tion  on  an  ad-hoc  basis. 

h)  Provide  the  capability  to  properly  interface  between 
automated  IMAPMIS  and  EPMAC  information  required  to 
produce  ACDUTRA  orders. 

i)  Provide  improvement  in  the  productivity  of  data  entry 
through  elimination  of  redundant  data  elements. 

j)  Provide  financial  management  with  system  data  suffi¬ 
cient  for  use  in  planning  and  budgeting  at  the  clai¬ 
mant,  OPTAR,  responsibility  and  Work  Center  levels. 

k)  Provide  the  capability  to  produce  hard-copy  transpor¬ 
tation  documents. 

The  RESFMS  hardware  consists  of  a  UNIVAC  1100/60 
host  computer  (owned,  operated,  and  maintained  by  NARDAC  New 
Orleans) ,  which  contains  the  database  and  all  data  proces¬ 
sing  and  storage  capabilities.  Users  at  CNRF  headquarters 
have  access  to  the  computer  via  VDT  terminals  with  direct, 
on-line  access  to  the  computer.  The  equipment  to  support 
the  phase  2  implementation  includes  the  hardware  in  place, 


on  order,  or  planned  to  support  RTSS  at  the  echelon  4  and  5 
levels . 

RESFMS  data  files  are  designed  and  organized  based 
on  UNIVAC's  Data  Management  System  ( DMS )  1100  which  is  a 

CODAS YL  standard  network  database  system.  There  are 
approximately  1400  application  programs  written  in  COBOL 
developed  by  NARDAC  and  SYSCOM  (an  outside  contractor) .  In 
addition,  DMS  1100  also  has  a  Query  Language  Processor  (QLP) 
software  package  that  is  used  to  support  ad  hoc  application 
requirements  on  a  limited  basis.  Limited  because  the 
processing  overhead  required  for  running  it  is  very  high. 
Finally,  a  non-procedural  language  software  package,  MAPPER, 
is  available  to  support  additional  ad  hoc  user  needs. 

RESFMS  interfaces  with  a  number  of  other  systems  and 
subsystems.  The  five  subsystems  within  RESFMS  are:  ACDUTRA 
order  writing,  financial  management,  RPN  accounting,  travel, 
and  program  management.  The  RESFMS  database  serves  as  the 
sole  repository  for  all  data  entered  manually  into  the 
system  by  the  users,  and  for  data  obtained  from  other 
systems  which  interface  with  it.  This  database  is  fed  from 
the  following  external  systems: 

a.  NRPC  provides  personnel,  mobilization  and  unit  address 
data  from  the  IMAPMIS  system  via  magnetic  tape  for  use 
in  the  production  of  ACDUTRA  orders. 

b.  The  Enlisted  Personnel  Management  Center  ( EPMAC)  pro¬ 
vides  unit  active  address  status  data  via  magnetic 
tape  for  use  in  the  production  of  ACDUTRA  orders. 


c.  Integrated  Disbursing  and  Accounting  (IDA)  expenditure 
transactions  are  passed  from  the  FIPC/IDA  system  to 
the  RPN  accounting  subsystem  via  magnetic  tape. 

d.  STOCKFUND  expenditure  transactions  are  passed  to  the 
RPN  accounting  subsystem  via  magnetic  tape. 

e.  Centralized  Expenditure/Reimbursement  Processing  Sys¬ 
tem  (CERPS)  expenditure  transactions  are  passed  to  the 
RPN  Accounting  subsystem  via  magnetic  tape. 

On  a  daily  basis,  RESFMS  supplies  ACDUTRA  informa¬ 
tion  to  RTSS  and  on  magnetic  tape.  This  eliminates  redun¬ 
dant  entry  of  ACDUTRA  data  related  to  training  for  the  RTSS, 
but  it  does  not  eliminate  the  redundant  entry  of  this  infor¬ 
mation  for  the  IMAPMIS  system. 

In  anticipation  of  the  extension  of  the  ACDUTRA 
subsystem  to  the  field  activities  (which  is  now  taking 
place) ,  CNRF  conducted  studies  to  determine  the  most  effec¬ 
tive  means.  The  two  possibilities  were  to  extend  the 
already  on-line  interactive  system,  or  to  go  to  a  distri¬ 
buted  system.  The  decision  had  to  be  based  not  only  on  the 
ACDUTRA  program,  but  had  to  also  consider  the  issues  of 
costs,  long-term  CNRF  and  DoD  information  systems  planning, 
availability  of  existing  hardware,  hardware  for  which  funds 
had  been  programmed,  and  development  of  telecommunications 
support.  An  economic  analysis,  addressing  these  issues,  was 
completed  early  in  1984.  The  result  was  that  RESFMS  will  be 
extended  to  the  field  as  a  distributed  system. 

In  the  distributed  configuration,  selected  proces¬ 
sing  capabilities  and  databases  are  distributed  to  field 
activities.  The  central  database  will  remain  on  the  UNIVAC 


1100/60.  Database  subsets  will  exist  at  designated  proces¬ 
sing  centers.  They  are  to  be  updated  by  a  two-way  process 
of  down/up-loading  from  the  central  database.  This  system 
configuration  is  pictured  in  Figure  2-7. 

In  operation,  ACDUTRA  applications  would  be  entered 
in  the  system  at  selected  field  activities.  Information  on 
the  applications  is  validated  against  personnel  data  from 
the  local  database.  Applications  are  then  flagged  for 
routing  to  the  appropriate  approval  authority.  At  speci¬ 
fied  intervals  during  the  day,  applications  are  file- 
transferred  over  telecommunications  facilities  to  the 
appropriate  locations.  Software  for  approval  procedures  at 
these  locations  enable  the  approval  authority  to  further 
process  the  application  and  approve  or  disapprove  it.  Dis¬ 
approved  applications  are  then  file-transferred  back  to  the 
point  of  entry.  Approved  applications  are  file-transferred 
to  procram  managers  at  CNRF  headquarters.  After  final 
approval  at  CNRF,  the  complete  application  is  file  trans¬ 
ferred  back  to  the  point  of  entry  where  orders  are  printed 
on  local  printers.  In  addition,  the  transportation  subsys¬ 
tem  interface  will  make  it  possible  to  also  have  the  airline 
tickets  printed  at  the  point  of  entry. 

The  procedures  described  above  represent  a  dramatic 
improvement  in  efficiency  over  the  non-automated  procedures. 
The  phase  2  implementation  is  slowly  (incrementally)  taking 


An  analysis  of  this  system  shows  that  it  has 
realized  most  of  the  objectives,  for  which  it  was  designed. 
The  cause  of  the  crisis  which  precipitated  the  development 
of  the  system,  the  six  month  lag  in  RPN  accounting  transac¬ 
tion  posting  from  the  execution  or  cancellation  of  ACDUTRA 
orders,  has  disappeared.  The  system  provides  virtually  up 
to  the  minute  RPN  accounting  information.  The  improved 
efficiency  which  has  resulted  from  the  automated  ACDUTRA 
processing  procedures  has  made  possible  the  elimination  of 
the  order  writing  division  of  the  Manpower  department  at 
CNRF  and  has  also  enabled  all  echelons  of  the  organization 
to  perform  ACDUTRA  processing  in  a  much  faster  and  more 
reliable  fashion. 

One  shortfall  of  the  system  is  that  it  has  not 
really  increased  the  effectiveness  of  the  program  manage¬ 
ment  function.  This  relates  directly  to  the  objective  of 
having  the  capability  to  access  information  and  produce 
reports  on  an  ad  hoc  basis.  However,  this  is  really  a  minor 
criticism  of  the  implementation,  not  the  planning  or  design, 
of  the  system. 

A  more  serious  concern  is  with  the  telecommunication 
costs.  The  design  of  the  system  called  for  it  to  use  the 
NARDAC  network  until  DDN  is  operational  throughout  the  Naval 
Reserve.  This  means  using  leased  lines  to  connect  the 
distributed  processing  sites  to  the  nearest  NARDAC  node. 
The  telecommunications  costs  are  already  considerable  and 


will  only  increase  as  more  field  activities  are  brought  on¬ 
line.  Although  the  Na^val  Reserve  is  not  now  on  the  DDN, 
there  is  some  concern  as  to  whether  being  part  of  the  DDN 
will  solve  the  problem.  It  would  be  significantly  cheaper, 
now,  for  the  distributed  sites  to  tie  into  the  closest  DDN 
host  or  TAC  than  it  is  to  go  to  the  nearest  NARDAC  node. 
This  is  pictured  in  Figure  2-8,  where  the  dotted  lines 
represent  the  distance  to  the  DDN  entry  points  and  the  solid 
lines  represent  the  distance  to  the  NARDAC  Network  entry 
points.  Why  isn't  this  being  done?  Because  the  NARDACs  are 
not  part  of  the  DDN.  Unless  this  problem  is  resolved  the 
ballooning  communication  costs  could  eventually  bring  this 
system  to  its  knees. 

There  seems  to  be  little  fault  to  find  with  the 
design  process  used  in  RESFMS.  Again  we  see  a  development 
process  called  "heuristic,”  but  unlike  RTSS,  this  one  has 
been  fairly  successful.  It  has  been  a  process  in  which  the 
system  has  been  developed  step  by  step  with  constant  consul¬ 
tation  and  trial  by  users.  This  method  was  intentionally 
chosen  (again  a  contrast  to  RTSS)  to  avoid  the  usual  pit- 
falls  of  a  system  that  had  been  designed  from  the  top  down 
by  analysts  before  users  had  any  real  chance  to  try  out  the 
product.  The  heuristic  design  philosophy,  in  this  case,  is 
a  refreshing  departure  from  the  rigid  and  often  inappro¬ 
priate  Life  Cycle  Management  model  of  system  design. 
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E .  SUMMARY 

This  has  necessarily  been  a  broad-brush  simplified  view 
of  the  structure  and  information  flows  of  the  Naval  Reserve. 
Its  purpose  was  to  familiarize  the  reader  with  the  organiza¬ 
tion  and  its  functions  in  a  general  fashion.  Any  systems 
planning  methodology  would  need  to  perform  a  much  more 
sophisticated  refinement  of  the  information  presented  in 
this  chapter. 


Ill .  STRATEGIC  INFORMATION  SYSTEMS  PLANNING 


A.  INTRODUCTION 

Planning  is  not  a  popular  activity  in  many  organiza¬ 
tions.  It  deals  with  a  distant  and  uncertain  future.  Any 
benefit  comes  later,  as  does  the  satisfaction  it  would 
provide.  There  is  no  perceived  immediate  advantage  to 
planning.  In  fact,  the  immediate  effects  seem  to  be  only 
negative.  Planning  takes  valuable  manpower  away  from  the 
day  to  day  business.  Often  it  is  felt  to  be  of  more 
importance  to  solve  the  immediate  crisis  than  to  give  con¬ 
sideration  to  more  distant  effects.  This  is  particularly 
true  in  the  military,  where  immediate  crises  abound,  and 
where  no  one  is  in  any  job  long  enough  to  realize  (take 
personal  credit  for)  the  benefits  of  strategic  planning. 
Planning's  reputation  has  been  further  tarnished  by  the  fact 
that  it  has  often  been  carried  out  as  a  meaningless  mandated 
ritual,  doomed  to  a  forgotten  existence  on  some  dusty 
bookshelf . 

A  heavy  price  has  been  paid,  in  many  instances,  for 
failure  to  plan  adequately.  A  considerable  fraction  of  the 
less  successful  information  systems  undoubtedly  suffer  from 
poor  planning  and  implementation.  Better  strategic  informa¬ 
tion  systems  planning  can  help  assure  that  resources  will  be 
applied  in  the  future  in  a  near  optimal  manner  and  that 
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systems  development  fiascos  of  the  kind  that  have  plagued 


many  organizations  in  the  past  will  be  avoided.  At  its 
best,  planning  can  make  it  possible  to  select  systems 
projects  that  offer  the  greatest  future  benefits  to  managers 
and  other  users;  projects  that  extend  the  role  of  informa¬ 
tion  systems  into  critical  areas  from  strategic  to  opera¬ 
tional  management. 

What,  exactly,  is  strategic  information  systems  plan¬ 
ning?  The  answer  often  depends  on  who  you  ask.  In  some 
instances,  application  project  plans  have  been  labelled  as 
"strategic"  plans.  In  others,  planning  goals  have  been  so 
broadly  stated  that  they  bear  little  relevance  to  the  prac¬ 
tical  problems  of  systems  management.  Clearly,  a  reasonable 
definition  lies  somewhere  between  these  two  extremes.  The 
available  literature  does  not  reveal  a  clear  consensus  as  to 
the  nature  and  scope  of  this  kind  of  planning  activity. 
Strategic  information  systems  planning  is  concerned  with 
formalized  and  disciplined  approaches  to  identifying 
requirements  beyond  the  immediate  future.  The  environmental 
pressures  making  this  type  of  planning  necessary  are  the 
increasing  complexity  of  information  systems  which  require 
an  increasingly  large  share  of  the  organization's  resources 
and  are  typified  by  long  lead  time  development  processes. 
Organizations  can  no  longer  afford  not  to  plan. 


Planning  is  the  process  of  formulating  a  program  of 
action  which  systematically  outlines  the  steps  and 


procedures  required  to  achieve  a  goal  (long  term)  or 
objective  (shorter  term) .  Strategic  planning  has  to  do  with 
the  overall  conduct  of  large  scale  operations.  It  reflects 
the  concern  of  top  management  with  the  future  direction  and 
needs  of  the  organization. 

The  remainder  of  this  chapter  will  explore  the  following 
issues : 

1)  How  to  determine  the  proper  quantity  and  quality  of 
strategic  information  systems  planning  required  by  an 
organization;  and,  using  those  guidelines,  determine 
what  is  appropriate  for  the  Naval  Reserve. 

2)  Evaluate  IBM's  Business  Systems  Planning  (BSP)  in 
relation  to  other  planning  methodologies. 

3)  Determine  how  strategic  information  systems  (IS)  plan¬ 
ning  is  currently  being  performed  in  the  Naval  Reserve 
organization . 

B.  INFORMATION  SYSTEMS  PLANNING — HOW  MUCH  IS  ENOUGH? 

Strategic  planning,  by  itself,  does  not  necessarily 
include  information  systems  planning.  By  the  same  token, 
information  systems  planning  does  not,  of  necessity,  have  to 
be  closely  tied  to  corporate  strategic  planning.  How 
closely  coupled  the  two  should  be  is  dependent  on  the  role 
of  MIS  within  the  organization.  If  the  function  is  one  of 
only  periphery  support,  such  as  payroll  processing,  then  it 
may  be  inappropriate,  or  at  least  unnecessary,  for  IS  plan¬ 
ning  to  be  concerned  with  corporate  strategic  planning.  On 
the  other  hand--and  this  is  becoming  more  the  norm  as  infor¬ 
mation  systems  become  integrated  into  more  business  areas-- 
if  the  organization  has  a  critical  dependence  on  their 


information  systems,  then  the  two  planning  processes  need  to 
be  closely  related.  For  some  organizations,  IS  activities 
represent  an  area  of  great  strategic  importance,  while  for 
others  they  play  a  cost-effective  and  useful  role  but  one 
which  is  distinctly  supportive  in  nature.  There  is  not  a 
discrete  difference  between  these  two  organizational 
environments.  They  should  more  accurately  be  viewed  as  two 
ends  of  a  continuum.  The  key  is  to  determine  the  location 
of  any  specific  organization  along  that  continuum;  to  ascer¬ 
tain  the  criticalness  of  IS  activities  in  relation  to  the 
company  achieving  corporate  goals. 

The  idea  of  strategic  impact  of  IS  is  just  one  of 
several  contingencies  that  should  be  considered  in  the 
development  of  a  comprehensive  planning  process.  Such  a 
planning  process,  to  be  effective,  must  also  deal  with  the 
realities  of  the  organizational  culture,  planning  culture, 
and  stage  of  IS  development.  The  idea  of  strategic  impact 
is  the  only  one  which  will  be  explicitly  dealt  with  in  this 
section.  The  other  considerations  will  be  examined  in 
Section  D  of  this  chapter. 

In  the  case  of  the  Naval  Reserve  this  issue  should  be 
addressed  on  at  least  two  separate  levels.  One  level  stems 
from  the  fact  that  the  Naval  Reserve  is  not  an  autonomous, 
independent  organization,  but  an  integral  part  of  a  larger 
Navy.  Therefore,  it  makes  sense  for  it  to  have  some  role  in 
the  information  systems  planning  process  for  the  entire 


Navy.  It  will  surely  be  a  recipient  of  the  plan  regardless 
of  whether  it  participates  in  the  planning  process.  By  the 
same  reasoning,  an  awareness  of  the  Navy's  overall  strategic 
information  systems  plan  is  a  necessary  input  to  the  Naval 
Reserve's  information  systems  planning  process. 

The  second  level  of  IS  planning  is  that  which  takes 
place  within  and  for  the  Naval  Reserve.  This  planning  is 
based  primarily  on  the  internal  -  requirements  of  the  organi¬ 
zation  without  being  overly  concerned  with  outside  factors. 
The  analysis  of  this  section,  as  well  as  the  larger  issue  of 
BSP  suitability,  will  be  in  the  context  of  this  planning 
environment.  The  Navy  has  its  strategic  information  systems 
planning  process,  of  which  the  Naval  Reserve  is  one  part; 
and  the  Naval  Reserve  has  its  own  internal  planning  process 
which  is  in  turn  affected  by  the  larger  total  Navy  process. 

The  current  role  of  IS  within  the  Naval  Reserve  is  one 
mainly  of  support,  but  a  kind  of  support  that  is  becoming 


increasingly  more  mission  critical, 


RTSS  and  RESFMS , 


although  important,  were  probably  not  originally  to  be  con¬ 
sidered  mission  critical  systems.  The  evolution  of  these 
systems,  however,  is  toward  a  more  integrated  and  pervasive 
role  within  the  organization.  RESFMS  impacts  on  many  more 
functional  areas  than  does  RTSS.  This  trend  argues  for  IS 
planning  to  become  more  closely  tied  to  the  strategic  plan¬ 
ning  activities  of  top  management.  This  would  help  insure 


that  future  IS  development  effectively  expands  into  the 
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crucial  functional  areas  of  the  organization.  Where,  in  the 
past,  the  IS  planning  process  did  not  need  to  be  closely- 
tied  to  the  overall  corporate  planning  process,  the  growing 
dependence  on  these  systems  requires  that  the  two  processes 
become  more  in  tune.  The  complex  task  of  effectively  manag¬ 
ing  the  Naval  Reserve  is  fast  reaching  the  point  where  it 
will  be  critically  dependent  on  automated  information 
systems.  There  is  little  doubt  but  that  current  levels  of 
ACDUTRA  and  Weekend  Away  Training  (WET)  could  not  be 
supported  without  RESFMS.  A  successful  mobilization  of  the 
Naval  Reserve  could  not  happen  without  a  system  with  the 
ability  to  quickly  retrieve,  update,  and  communicate  large 
amounts  of  accurate  data. 

The  successful  management  of  the  Naval  Reserve  hinges  on 
an  effective  IS  planning  system.  The  evaluation  of  any  IS 
planning  methodology  must  consider  how  well  it  interacts 
with  the  top-level  strategic  planning  process.  Gone  are  the 
days  when  IS  planning  could  afford  to  be  an  isolated  myopic 
process.  Strategic  information  systems  planning  in  the 
Naval  Reserve  calls  for  a  well-articulated,  coherent,  and 
effective  methodology.  The  cost,  complexity,  and  growing 
criticalness  of  these  systems  demands  it. 

C.  THE  BUSINESS  SYSTEMS  PLANNING  (BSP)  METHODOLOGY 

Information  systems  planning  is  a  process  that  uses  a 
descriptive  model  to  reflect  the  detailed  methods  of  the 
organization's  mission.  The  planning  methodology  builds 


this  model  by  decomposing  the  data,  processes,  and 
data/people  relationships.  The  degree  of  effectiveness  of 
the  system  (s)  that  are  subsequently  developed  from  this 
model  will  depend  on  how  well  the  model  represents  the 
reality  of  the  organization.  The  underlying  assumptions  of 
different  planning  methodologies  will  affect  the  usefulness 
of  the  resulting  models.  The  tools  with  which  the  model  is 
built  are  as  important  as  the  pieces  of  the  model.  They 
will,  in  essence,  determine  what  those  pieces  will  be.  It 
is  i mperat . vo  t h  at  an  appropriate  methodology  is  used 
because  t".:-  retro:  •  .  :y  will  determine  what  is  analyzed  and 

The  ;  ;  sr.  :  rpcrtant  element  of  the  planning 
pro  -o  :  .*  only  one  part.  The  intrinsic 
or.v . :  "  t  :  ;  *  :  :  the  organization  that  were  dis¬ 
cuss-  :  .o  section  also  need  to  be  considered  in 
deve  1  :  .  :  r  .  i  s  1  i n r. :  r.g  process  . 

This  section  will  not  attempt  to  answer  the  question  of 
whether  BSP  is  the  right  methodology  for  the  Naval  Reserve. 
The  intent  here  is  to  point  out  how  it  differs  from  other 
methodologies  and  examine  its  strengths  and  weaknesses  in 
that  context  only.  This  section  will  provide  an  important 
part  of  the  conceptual  foundation  that  will  make  it  possible 
to  answer  that  larger  question  in  a  rational  manner. 
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In  the  broadest  sense  planning  methodologies  can  be  said 
to  focus  on  technology,  data,  or  information.  A  technology- 
based  methodology  is  concerned  with  the  management  of 
applications  and  processing.  It  views  the  technology  as  the 
corporate  resource  around  which  the  planning  should  be 
based.  The  Stages  of  Growth  (SOG)  model  is  of  this  type. 
The  data-based,  or  datalogical,  models  see  the  organization 
in  the  context  of  data  objects  which  are  processed  at 
various  organizational  levels  to  form  information  objects  at 
other  organizational  levels.  Data  Flow  Diagrams  ( DFD) , 
Structured  Analysis  and  Design  Technique  (SADT) ,  and 
Systematic  Activity  Modeling  Method  (SAMM)  are  in  the  data¬ 
logical  category.  The  third  category  is  the  information- 
based,  or  infological,  models.  Their  focus  is  on  the 
information  structure  of  an  organization.  They  generally 
take  a  more  macro  perspective  of  the  organization  than  the 
datalogical  models.  They  try  to  determine  what  is 
information  to  what  level  in  the  organization,  who  owns  the 
information,  and  who  needs  the  information.  BSP,  as  well  as 
Business  Information  Analysis  and  Integration  Technique 
( BIAIT)  and  Critical  Success  Factors  (CSF) ,  is  representa¬ 
tive  of  this  category. 


The  datalogical  models  provide  a  detailed  view  of  each 
process  or  task,  which  facilitates  the  IS  design.  On  the 
other  hand,  this  microscopic  view  often  forces  the 


forfeiture  of  top  management  involvement.  The  big  picture 
is  hidden  by  the  mass  of  detail. 

The  infological  models  concentrate  on  the  macro  view  to 
the  extent  that  the  exact  details  of  how  a  system  will 
accomplish  the  processes  and  tasks  are  not  explicitly 
defined.  This  promotes  top  management  involvement  while 
making  the  IS  design  problem  more  difficult  (than  the  data¬ 
logical  approach) . 

All  the  models  will  not  be  examined  here.  Those  that 
are  will  be  so  only  to  the  degree  necessary  for  background 
in  describing  BSP.  The  purpose  of  this  thesis  is  not  to 
find  the  best  IS  planning  methodology  but  to  evaluate  the 
suitability  of  BSP. 

Stages  of  Growth  (SOG)  [Ref.  8]  was  the  first  of  the 
planning  methodologies  to  be  widely  used.  It  was  in  vogue 
at  a  time  when  the  first  large  scale  systems  development 
projects  were  being  undertaken.  It  is  still  in  use  today, 
although  not  as  an  explicit  planning  model.  It  derived  from 
the  social  sciences  a  notion  that  organizations  must  assimi¬ 
late  this  kind  of  change  through  a  predictable  sequence  of 
steps  at  a  modest  pace.  It  is  based  on  the  theory  that  the 
sequence,  with  stages  of  initiation  and  expansion  followed 
by  consolidation  and  maturity,  would  be  similar  for  all 
organizations.  The  focus  of  SOG  is  on  the  management  of 
technology.  This  planning  approach  has  been  seriously  dated 
by  technological  change  which  has  forced  a  change  in  the 
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planning  perspective,  with  the  emphasis  shifting  from 
applications  and  processing  management  to  data  and  informa¬ 
tion  resource  management  [Ref.  9].  This  is  not  to  say  that 
SOG  is  not  a  valid  descriptive  model,  only  that  it  is  not 
complete  enough  to  be  a  basis  for  comprehensive  IS  planning. 
It  realistically  stresses  the  need  for  an  organization  to 
know  where  it  stands  today  before  trying  to  plan  where  it 
can  go  tomorrow. 

The  planning  response  to  the  new  environment  caused  by 
technological  change  is  well  represented  by  IBM's  Business 
Systems  Planning  (BSP)  package.  "BSP  focuses  less  on 
developing  organizational  structures  and  disciplines 
necessary  to  manage  the  computer  room  than  on  conceptualiz¬ 
ing  and  designing  the  overall  corporate  data  resource." 
[Ref.  9:p.  4]  As  an  evolution  of  systems  planning  it 
changes  the  goal  from  one  of  following  universally  described 
actions  to  one  of  developing  highly  customized  goals. 
Architectural  recommendations  are  derived  from  the  construc- 
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tion  of  an  empirical  model  of  the  business  enterprise. 

BSP  seeks  to  provide  such  a  plan  by  emphasizing  a  top- 
down  approach  to  analysis  that  builds  an  infological  model. 
The  key  to  the  success  of  the  top-down  approach  is  in 
getting  people  involved,  starting  with  top  management  and 
working  down.  The  analysis  stresses  the  perspective  of  top 
management  by  working  from  the  broad  to  the  detail  level. 
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Through  this  analysis  BSP  attempts  to  translate  business 
objectives  to  information  requirements. 

BSP  provides  a  structured  methodology  that,  if  properly 
followed,  would  show  the  organization  the  logical  way  they 
deal  with  data  classes  (information)  and  groupings  (of  data 
classes)  that  would  reflect  major  activities  of  information 
handling.  The  study  determines  information  flow  within  an 
organization.  It  displays  the  information/subsystem  rela¬ 
tionships  and  the  processes  supported  by  each  subsystem. 
These  results  can  then  furnish  a  basis  for  informed  informa¬ 
tion  resource  decisions.  This  is  where  computer  support  and 
development  priorities  can  be  made.  These  implementation 
priorities  are  determined  as  part  of  a  comprehensive  plan 
evolving  from  current  systems.  Broadly  stated,  BSP  stresses 
top-down  design  and  bottom-up  implementation. 

An  important  basic  assumption  of  the  BSP  methodology  is 
that  an  organization  should  view  data  as  a  resource  that  is 
as  important  as  personnel,  cash,  facilities,  or  materials. 
It  assumes  that  in  order  for  management  to  have  a  wider 
perspective  of  the  organization  and  to  be  in  a  position  to 
make  effective  multifunctional  decisions,  information  should 
be  available  not  just  to  individual  functions  or  departments 
but  throughout  the  business.  The  assumption  is,  in  short, 
that  the  organization  has  a  need  for  a  company-wide 
information  system. 


The  BSP  methodology  presumes  this  conceptual  perspective 

as  a  starting  point.  Some  of  the  organizational  elements 

that  it  sees  as  impediments  to  the  successful  development  of 

company-wide  information  systems  are:  that  executive 

commitment  and  involvement  have  been  absent  from  the 

planning  process;  that  IS  objectives  and  strategies  are  not 

consistent  with  the  organization's  overall  business 

(mission)  objectives;  that  the  company-wide  systems  have  not 

been  developed  as  part  of  a  comprehensive  plan  evolving  from 

current  systems;  and  that  information  resource  management 

functions  have  not  been  put  in  place  to  adequately  manage 

the  resources.  The  Naval  Reserve  has  exhibited,  to  varying 

degrees,  all  of  those  tendencies.  The  BSP  methodology  was 

developed  to  abate  those  organizational  factors.  The  output 

of  this  methodology  should  be  a  dynamic  viable  IS  plan. 

An  information  system  plan  should  allow  a  modular  approach 
to  implementation,  providing  confidence  that  each  module 
will  fit  and  function  properly  to  form  an  integrated 
system  and  will  interface  properly  with  the  present 
operational  systems.  The  plan  should  also  allow  for 
better  decisions  concerning  the  efficient  and  effective 
commitment  of  information  system  development  resources. 
With  such  a  plan,  the  required  information  can  be  more 
readily  obtained.  [Ref.  I0:p.  1] 

One  of  the  criticisms  of  BSP  is  common  to  all  infologi- 
cal  models,  and  that  is  that  it  does  not  readily  provide  a 
language  for  the  system  analyst  to  perform  detailed  system 
design.  BSP  does,  however,  seem  to  provide  a  better  link  to 
this  type  of  activity  than  do  most  other  infological  models. 
This  shortcoming  should  be  considered  in  light  of  the 


objectives  of  strategic  planning  which  concern  the  develop¬ 
ment  of  information  systems  in  long-range  general  terms. 
What  BSP  can  provide  is  a  comprehensive  methodology  for 
understanding  the  processes  of  an  organization  in  terms  of 
information  needs. 

The  next  chapter  will  consider  the  exact  steps  of  the 
methodology  in  much  more  specific  detail  in  the  context  of 
the  Naval  Reserve.  The  purpose  of  this  section  has  been  to 
introduce  the  conceptual  basis  and  objectives  of  BSP. 

D.  NAVAL  RESERVE  INFORMATION  SYSTEMS  PLANNING 

In  concert  with  the  attributes  of  IS  planning  put  forth 
in  Section  B,  two  planning  perspectives  will  be  considered 
here.  One  will  be  the  Naval  Reserve's  role  in  Navy  IS 
planning;  the  other  will  be  that  planning  which  takes  place 
within  and  for  the  Naval  Reserve.  This  section  will  also 
explore  the  influence  of  organizational  and  planning  culture 
on  IS  planning  within  the  Naval  Reserve.  The  focus  of  this 
discussion  will  be  on  long-range  strategic  planning  activi¬ 
ties  rather  than  on  specific  system  design. 

In  May  1983  the  National  Academy  of  Sciences  reviewed 
the  Navy's  ADP  management  processes  and  made  recommendations 
for  improvements.  One  of  the  recommendations  was  that  the 
Navy  develop  a  high-level  information  architecture  which 
depicts  the  flow  of  functional  information  needed  to  conduct 
the  Navy's  business.  OP-94  is  responsible  for  developing 
the  high-level  information  architecture;  and  the  Director, 


Total  Force  Information  Systems  Management  Division  (OP-16) 
is  responsible  for  developing  the  information  architecture 
for  manpower,  personnel,  and  training  (MPT)  functions.  OP- 
16  divided  the  MPT  world  into  functional  subareas.  In  order 
to  compile  the  information  needed,  OP-16  has  tasked  the 
organizations  with  primary  responsibility  for  the  selected 
functions  to  develop  subarchitectures.  Commander,  Naval 
Reserve  Force  is  one  of  these  organizations  and  is 
responsible  to  OP-16  in  this  planning  process. 

OP-16  has  been  working  on  a  methodology  that  uses  a  tri¬ 
level  hierarchy  of  architectures.  The  methodology,  still 
not  fully  articulated,  seeks  to  develop  first  an  "Informa¬ 
tion  Flow  Architecture"  than  a  "Data  Architecture"  and 
finally  a  "Technical  Architecture." 

The  information  flow  architecture  is  a  logical  model  of 
the  business  processes  of  an  organization.  It  is  meant  to 
be  the  highest  logical  level  of  abstraction  that  documents 
the  functional  activities  and  classes  of  information 
required  to  meet  the  mission  and  goals  of  the  organization. 
Information  flow  architectures  are  designed  to  show  the 
organizational  units  (subsystems)  that  participate  in  the 
business  processes.  Development  of  an  information  flow 
architecture  is  a  planning  process  that  identifies  the 
information  an  organization  requires  to  plan,  control,  and 
execute  its  mission.  The  intent  of  this  process  is  not  just 
to  document  the  current  information  flow  but  to  identify 
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associated  problem  areas  and  develop  recommended  "target" 
information  flows  to  correct  them. 

The  second  phase,  data  architecture  development,  is  an 
extension  and  refinement  of  the  information  flow  architec¬ 
ture  and  is  designed  to  produce  a  set  of  logical  models  that 
will  provide  the  basis  for  information  systems  planning. 
These  logical  models  should  reflect:  the  functions  of  the 
business  and  the  data  needed  to  accomplish  those  functions; 
the  structure,  characteristics,  and  interrelationships  of 
the  data;  and  the  availability  of  the  data  required  to 
support  the  organization. 

The  development  of  a  technical  architecture  is  the  third 
phase  of  this  planning  process.  This  architecture  is  a 
model  of  the  technical  resources  that  are  designed  to  the 
information  flow  and  data  architectures.  The  model  should 
depict  the  relationships  among  AISs,  communications  net¬ 
works,  data  bases,  or  computers  used  to  process  information. 
As  the  final  step  in  this  planning  methodology  developed  by 
OP-16,  the  development  of  a  technical  architecture  is  a 
design  process  that  conveys  to  the  user  how  technology  has 
or  will  be  applied  to  provide  the  information  required  by 
the  business  processes. 

This  methodology  is  not  inconsistent  with  the  objectives 
of  BSP.  It  is,  however,  not  as  rigorous  or  formalized  as 
the  BSP  methodology.  It  leaves  much  of  the  interpretation 
of  the  methodology  to  the  user.  This  inherent  ambiguity 


should  make  it  relatively  more  difficult  to  use.  It  will  be 
used,  however,  because  it  has  been  mandated  by  OP-16. 

This  planning  methodology  is  being  used  by  the  ADP  plan¬ 
ning  department  of  CNRF.  Its  usefulness,  however,  is 
suspect  for  it  appears  that  the  product  is  being  prepared 
for  external  consumption  only.  There  does  not  seem  to  be 
much  interest  within  the  Naval  Reserve  organization  in  this 
planning  process,  particularly  outside  of  the  ADP  planning 
department.  CNRF  is  participating  in  this  planning  process 
only  to  the  extent  that  they  have  been  ordered  to  do  so. 
This  seems  to  be  the  scope  of  the  Naval  Reserve's  role  in 
total  Navy  IS  planning.  In  fact,  a  good  case  could  be  made 
that  this  is  the  extent  of  formal  IS  strategic  planning 
being  accomplished  by  the  Naval  Reserve. 

Any  strategic  IS  planning  that  is  taking  place  within 
and  for  the  Naval  Reserve  is  being  done  not  as  part  of  some 
formal  process  but  through  the  default  method  of  planning 
through  neglect.  Internal  strategic  planning  does  not  seem 
to  be  taking  place.  The  type  of  planning  that  is  being  done 
is  neither  formalized  nor  consistent  and  is  generally  of  a 
short  time  horizon  (less  than  5  years — typically  much  less) . 
At  its  best  it  is  tactical  planning  working  toward  specific 
isolated  objectives  without  any  enunciation  of  overall 
business  goals.  This  is  the  type  of  planning  of  which 
RESFMS  is  a  result.  At  its  worst  it  is  strictly  political; 


the  consequence  of  someone  selling  their  latest  idea  to  the 


Admiral.  Internal  IS  planning  is  typified  by  different 
factions  planning  diverse  projects  with  no  thought  being 
given  to  compatibility  or  long-range  interoperability. 

This  type  of  planning  can  best  be  explained  as  part  of 
the  organizational  culture  and,  to  a  lesser  degree,  the 
planning  culture.  The  Naval  Reserve's  organizational 
culture  is,  in  many  respects,  a  microcosm  of  the  larger  Navy 
culture.  In  this  respect  it  is  a  hierarchical  bureaucracy 
with  a  well-established  chain  of  command.  It  can  also  be 
characterized  as  a  highly  centralized  organization. 
Although  it  is  geographically  dispersed  it  is  functionally 
centralized.  The  organizational  culture  of  the  Naval 
Reserve  is  probably  more  politicized  than  that  of  the  Navy 
in  general.  That  is,  much  of  the  organizational  behavior 
can  be  explained  by  the  internal  politics  of  the 
organization. 

The  planning  culture  of  the  Naval  Reserve  has  two  faces: 
one  is  the  formal,  as  exemplified  by  the  Planning,  Program¬ 
ming,  and  Budgeting  System  (PPBS) ;  the  other  is  the 
informal,  ad-hoc,  and  often  reactionary  planning  that  is 
part  of  the  day-to-day  operation.  The  PPBS  process  has 
minimal  impact  on  strategic  IS  planning  primarily  because  it 
is  budget  focused.  It  is  oriented  toward  individual  line 
items.  The  core  of  this  type  of  planning,  in  the  IS 
environment,  is  on  specific  projects  vice  the  management  of 
the  overall  data  resource.  The  informal  planning  culture 
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has  a  much  more  direct  influence  on  IS  planning  because  it 
is  within  the  context  of  that  culture  that  most  IS  planning 
is  taking  place.  This  is  crisis-driven  planning,  person¬ 
ality-driven  planning,  planning  that  takes  place  as  a 
byproduct  of  bureaucratic  inertia.  It  is  the  desire  to  see 
immediate  results,  the  kind  that  can  be  reflected  on  fitness 
reports.  It  is  primarily  due  to  the  influence  of  this 
planning  culture  that  little  or.no  strategic  IS  planning  is 
taking  place.  In  fact,  one  would  be  hard-pressed  to  find 
reasonable  examples  of  any  type  of  strategic  planning  taking 
place  within  the  Naval  Reserve. 

E .  SUMMARY 

It  has  been  the  intent  of  this  chapter  to  explore  some 
of  the  conceptual  and  practical  aspects  of  strategic  IS 
planning.  The  BSP  methodology  was  introduced  in  that 
context.  An  important  distinction  was  made  between  a 
planning  methodology  and  the  planning  process.  The  planning 
methodology  is  just  one  part,  albeit  an  important  one,  of 
the  planning  process.  An  assessment  of  IS  planning  in  the 
Naval  Reserve  showed  that  planning  is  taking  place  without 
the  benefit  of  any  formal  methodology.  The  type  of  planning 
that  is  taking  place  within  the  Naval  Reserve  is  largely 
ineffective  because  the  organizational  factors  working 
against  strategic  planning  are  more  influential  than  those 


IV.  THE  BSP  STUDY 

A.  INTRODUCTION 

The  Business  Systems  Planning  (BSP)  methodology,  as 
developed  by  IBM,  is  a  structured  methodology  based  on  the 
premise  that  .  .  there  exists  within  the  organization  a 
need  for  significantly  improved  computer-based  information 
systems  (IS)  and  a  need  for  an  overall  strategy  to  attain 
them."  [Ref.  10:p.  5]  As  was  pointed  out  in  the  last 
chapter,  because  information  systems  are  fast  becoming  a 
critical  component  of  the  Naval  Reserve  and  because  they 
will  continue  to  represent  major  investments  of  time  and 
money,  it  is  essential  that  they  support  the  organization's 
true  business  needs  and  directly  influence  its  objectives. 
BSP  offers  a  process  that  can  translate  business  strategy 
into  IS  strategy.  If  the  organization  does  not  have  an 
apparent  business  strategy,  as  seems  to  be  the  case  of  the 
Naval  Reserve,  then  BSP  can  help  it  express  its  long-term 
goals  and  objectives.  Senior  management  recognition  of  the 
importance  of  articulating  long-term  goals  and  objectives 
will  help  guarantee  a  meaningful  BSP  study. 

Two  of  the  problems  manifest  in  the  Naval  Reserve  which 
BSP  is  designed  to  correct  are  data  inconsistencies  and  non- 
integrated  systems  design.  These  are  problems  that  are 
usually  a  result  of  the  "bottom-up"  evolution  of  systems. 
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The  data  inconsistency  problem  for  the  Naval  Reserve  is  not 
exhibited  as  much  between  their  internal  systems  as  they  are 
as  a  result  of  external  systems  interfaces.  This  is  a 
"bottom-up"  evolution  of  systems  in  the  context  of  the 
entire  Navy,  with  each  organization  developing  their  own 
systems.  The  question  is  whether  BSP  can  adequately  address 
this  situation.  This  is  not  to  say  that  there  are  not 
internal  reasons  for  these  problems,  only  that  some  of  the 
cause  is  external  to  the  organization. 

The  BSP  methodology  stresses  an  analysis  that  works  from 
the  top  down  and  an  implementation  strategy  where  the  infor¬ 
mation  support  is  implemented  in  a  modular  building-block 
fashion  over  time.  This  allows  the  implementation  of 
systems  to  remain  consistent  with  the  organization's 
business  priorities,  available  funds,  and  other  shorter-term 
considerations . 

The  first  step  of  the  BSP  analysis  is  to  define  the 
business  objectives.  This  requires  top-level  management 
involvement.  The  next  step  is  to  define  the  business  proc¬ 
esses  and  then  to  define  the  business  data.  This  data 
definition  is  accomplished  by  identifying  what  things 
(entities)  are  important  to  the  business  and  what  data  are 
required  to  manage  those  entities.  The  final  step  is  to 
define  the  information  architecture  which  becomes  a 
statement  of  the  long-term  IS  objective.  From  the 


information  architecture  the  individual  modules  can  be 
identified,  scheduled,  and  built. 

There  are  two  major  steps  (activities)  that  precede  a 
BSP  study  and  eleven  in  the  study  itself.  The  first  two 
are:  gaining  the  commitment;  and  preparing  for  the  study. 
The  eleven  major  activities  of  the  study  are:  starting  the 
study;  defining  business  processes;  defining  business  data; 
defining  information  architecture;  analyzing  current  systems 
support;  interviewing  executives;  defining  findings  and 
conclusions;  determining  architecture  priorities;  reviewing 
information  resource  management;  developing  recommendations; 
and  reporting  results.  The  remainder  of  this  chapter  will 
examine  these  steps  in  detail  in  the  context  of  the  Naval 
Reserve.  This  will  not  be,  by  any  means,  a  complete  study, 
only  a  general  examination  of  processes  and  data  sufficient 
for  evaluating  the  methodology.  The  level  of  detail 
required  for  a  full  BSP  study  is  well  beyond  the  scope  of 
this  thesis. 

B.  PRE-STUDY  ACTIVITIES 

The  success  of  a  BSP  study  depends  heavily  on  the 
commitment  of  all  the  participants.  An  assessment  of  the 
commitment  of  all  concerned  (particularly  at  the  executive 
level)  should  be  made  before  the  study  is  started.  Some  of 
the  other  activities  to  be  performed  during  this  phase 
include:  establishing  the  study  scope;  setting  the  objec¬ 
tives;  and  selecting  the  study  team. 
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The  scope  of  the  study  does  not  have  to  include  the 
whole  organization.  It  can  focus  on  just  one  department  or 
functional  area.  In  the  case  of  the  Naval  Reserve,  for 
instance,  it  could  be  limited  to  echelon  3  or  to  the  train¬ 
ing  function.  For  purposes  of  this  evaluation  the  entire 
Naval  Reserve  organization  will  be  examined.  A  full  BSP 
study,  if  undertaken  for  the  Naval  Reserve,  would  probably 
be  most  beneficial  if  its  scope  included  the  entire 
organization . 

Businesses  whose  activities  span  multiple  functional  units 
tend  to  gain  more  from  a  BSP  study  than  those  that  are 
more  simply  structured  since  BSP  deals  well  with  com¬ 
plexity.  It  is  designed  to  identify  the  requirements  for 
data  integration  across  multiple  functions.  [Ref.  10:p. 
14] 

One  of  the  most  important  commitments  is  the  commitment 
of  manpower  and  resources  to  the  study  team.  A  full  BSP 
study  will  require  4  to  7  people  full  time  for  8  to  12 
weeks.  These  team  members  should  not  be  the  6  most  junior 
officers  who  just  reported  aboard,  nor  should  they  come  from 
the  ADP  department.  They  need  to  be  from  upper  and  middle 
management  with  several  years  experience  in  the  Naval 
Reserve.  If  the  pressures  of  day-to-day  operations  make  it 
impossible  to  devote  this  amount  of  -manpower  to  the  study 
there  is  still  a  way  to  get  it  done.  This  other  option  is 
to  use  Selected  Reservists  (SELRES)  .  There  is  more  than 
enough  talent  available.  This  approach  has  been  used 
successfully  before.  [Ref.  5] 
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Once  the  commitment  of  all  participants  has  been  gained 
and  the  decision  made  to  continue  with  the  study  it  is 
necessary  to  complete  the  remaining  actions  that  lead  up  to 
the  actual  start  of  the  study.  During  this  phase  interview¬ 
ees  are  selected  and  scheduled,  a  study  work  plan  is 
developed,  business  and  IS  information  is  gathered,  and 
administrative  support  is  established.  At  this  time  a 
start-up  meeting  should  be  convened  and  full-time  activities 
will  commence.  This  start-up  activity  and  the  next  5  major 
activities  are  all  aimed  at  understanding  the  business 
requirements  and  data  processing  support  as  they  exist  today 
as  well  as  the  business  requirements  for  the  future. 

C.  DEFINING  BUSINESS  PROCESSES 

The  basic  step  for  gaining  an  understanding  of  how  the 
business  accomplishes  its  overall  mission  and  objectives  and 
for  defining  key  data  requirements  is  to  define  business 
processes.  Business  processes  are  defined  as  groups  of 
logically  related  decisions  and  activities  required  to 
manage  the  resources  of  the  organization. 

The  method  for  determining  the  processes  is  to  first 
identify  the  product/service  and  supporting  resources  of  the 
organization.  The  product  and  supporting  resources  life 
cycle  is  then  described.  For  purposes  of  this  discussion 
the  individual  reservist  will  be  looked  at  as  the  product  of 
the  organization.  The  life  cycle  stages  of  that  reservist 


are : 


to  recruit,  to  train,  to  mobilize,  to  retire. 


The 


supporting  resources  are  the  recruiting,  personnel  manage¬ 
ment  and  training  programs,  facilities,  and  pay.  There  are 
many  business  processes  that  could  be  identified  for  each  of 
these  resources  in  each  life  cycle  phase.  After  this  first 
rough  identification,  the  processes  are  then  grouped  or 
split  as  necessary  to  reduce  inconsistencies  and  commonali¬ 
ties.  The  team  should  then  write  a  description  of  each 
process. 

The  final  major  activity  of  this  step  is  to  relate  the 
business  processes  to  the  organization.  This  is  done 
through  the  development  of  a  process/organization  matrix. 
It  illustrates  the  degree  of  involvement  of  the  various 
organizational  units  in  each  of  the  processes.  The  four 
possible  degrees  of  involvement  are:  major  responsibility 
and  decision  maker  (X) ,  major  involvement  (X) ,  some  involve¬ 


ment  (/)  ,  and  no  involvement  (blank)  . 


A  simple 


process/organization  matrix  for  the  Naval  Reserve  is  shown 
in  Figure  4-1. 


D.  DEFINING  BUSINESS  DATA 

Once  the  business  processes  have  been  identified,  the 
next  step  is  to  identify  and  define  business  entities,  data 
classes,  and  their  relationships. 

A  business  entity  is  something  of  lasting  interest  to  an 
organization.  It  can  be  a  person,  place,  thing,  or  idea 
about  which  data  are  collected  and  stored.  They  are  what 
the  organization  manages  and  their  identification  serves  as 


Process/Organization  Mat 


a  basis  for  identifying  the  data  needs  of  the  organization. 
Each  entity  should  be  able  to  be  uniquely  identified.  Some 
of  the  business  entities  of  significance  to  the  Naval 
Reserve  are:  the  reservist,  billet,  reinforcing  (reserve) 
unit,  augmented  (active)  unit,  readiness,  appropriations, 
expenditures,  orders,  end  strength,  equipment,  facilities, 
and  schools.  Eac'  entity  should  be  carefully  defined  in 
detailed  and  complete  sentences.. 

The  second  part  of  this  process  is  to  specify  what  data 
must  be  available  and  what  data  are  created  by  each  business 
process.  Each  type  of  data  identified  is  then  matched  to 
the  entity  it  describes.  This  forces  a  clarification  of 
business  entities. 

The  knowledge  of  the  relationship  of  data  to  processes 
leads  directly  to  the  identification  of  data  classes.  A 
data  class  represents  a  category  of  information  about  an 
entity.  To  ensure  the  integrity  of  data,  there  must  be  no 
more  than  one  source  for  the  creation  of  each  data  class. 
The  final  step  in  this  activity  is  to  define  each  data  class 
completely . 


E.  .DEFINING  INFORMATION  ARCHITECTURE 


After  the  data  classes  have  been  identified,  it  is 
necessary  to  establish  the  relationship  between  data  classes 
and  business  processes.  The  tool  used  to  establish  these 
relationships  is  the  information  architecture  (process/data 
class  matrix) .  The  relation  can  be  one  of  three  types.  The 
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first  type  is  creation  (C)  ,  where  the  process  creates  the 
data  class.  The  second  relation  can  be  usage  (U) ,  where  the 
process  uses  the  data  class.  The  third  type  of  relation  is 
no  involvement  (blank) .  Once  all  the  relations  are  labeled, 
the  process/data  class  matrix  is  rearranged  so  that 
groupings  of  Cs  and  Us  begin  at  the  upper  left  and  move  to 
the  lower  right. 

What  is  the  benefit  of  all  this  relationship  labeling 
and  column  juggling?  The  groupings  that  are  obtained  from 
this  process  can  be  related  to  organizational  personnel  and 
structure.  That  is,  data  classes  (and  therefore  data  ele¬ 
ments)  are  grouped  into  proper  parts  of  the  organization.  A 
BSP  study  can  show  the  organization  the  logical  way  they 
deal  with  data  classes  (information)  ,  and  groupings  that 
would  reflect  major  activities  of  information  handling. 

The  next  step  is  to  identify  the  flow  of  data  between 
process  groups.  Whenever  there  is  data  used  by  a  process 
and  that  data  is  created  by  a  process  in  some  other  group, 
an  arrow  is  drawn  from  the  creating  group  to  the  using 
group.  When  all  Us  are  examined  and  the  necessary  data 
flows  represented,  the  result  will  be  a  flow  diagram. 

Figure  4-2  is  an  elementary  process/data  class  matrix 
that  has  been  transformed  into  a  flow  diagram  for  the  Naval 
Reserve.  The  process  column  starts  with  strategic  activi¬ 
ties  followed  by  a  mix  of  management  and  operational  control 
activities.  It  may  not  accurately  represent  all  the 
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information  flows  because  it  does  not  contain  the  level  of 
detail  necessary  to  precisely  reflect  the  processes  and  data 
classes  of  the  Naval  Reserve.  A  full  BSP  study  would 
further  decompose  and  refine  the  processes  and  data  classes 
shown  here.  The  significance  of  Figures  4-1  and  4-2  is  not 
in  the  information  they  contain  but  only  as  an  illustration 
of  how  the  matrices  would  be  used  in  analyzing  the  Naval 
Reserve. 

A  question  raised  at  the  beginning  of  this  chapter  was 
whether  BSP  could  adequately  consider  data  derived  from 
sources  external  to  the  organization.  This  situation  can  be 
represented  by  creating  a  separate  process  for  each  instance 
where  external  data  are  required.  These  processes  would 
then  become  the  creation  points  for  the  internal  representa¬ 
tion  of  those  data.  This  type  of  transformation  activity  is 
represented  by  the  "comply  with"  and  "input"  processes  in 
Figures  4-1  and  4-2. 

The  information  architecture  thus  developed  is  an  impor¬ 
tant  product  of  the  BSP  study.  It  yields  information  flow 
within  an  organization,  displaying  relationships  to  subsys¬ 
tems  and  the  processes  supported  by  each  subsystem. 

The  completed  architecture  drawing  is  a  very  useful 

management  communication  tool  because: 

*  It  is  the  team's  recommendation  for  long-range  informa¬ 
tion  systems  implementations. 

*  It  identifies  the  information  systems  (the  blocks  or 
boxes)  that  form  the  long-range  plan. 
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*  It  shows  the  data  controlled  by  each  information  system 
(reading  vertically) . 

*  It  shows  the  business  processes  supported  by  each 
information  system  (reading  horizontally) . 

*  It  shows  the  flow  of  information  between  the  various 
information  systems  (the  lines  and  arrows)  and  thus 
shows  the  flow  of  information  through  the  business 
itself.  [Ref.  10:p.  45] 

From  these  results,  information  resource  decisions  can  be 
made.  That  is,  decisions  concerning  subsystems  to  receive 
computer  support  and  development  priorities  of  the  computer 
subsystems  can  be  made. 

None  of  these  decisions,  however,  can  be  made  using  the 
simple  graphic  which  is  Figure  4-2.  About  all  that  can  be 
discerned  from  that  figure  is  that  it  seems  to  indicate  that 
all  aspects  of  the  management  of  the  reservist  are  closely 
related.  It  helps  explain  the  interfaces  and  duplication  cf 
data  that  exist  between  RTSS  and  RESFMS.  Even  this  simple 
graphic"  argues  for  the  integration  of  those  two  systems. 

F.  THE  FINAL  STEPS 

The  activities  up  to  this  point  have  been  to  look  at  the 
organization  in  terms  of  business  processes  and  the  data 
classes  necessary  to  perform  them.  The  next  step  in  the  BSP 
process  is  to  analyze  current  systems  support.  It  uses  the 
process  and  data  class  information  developed  by  the  previous 
steps.  Much  of  this  analysis  was  presented  in  a  different 
format  in  Chapter  II.  The  importance  of  this  examination  is 
to  ensure  that  computer  system  development  decisions  are 
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based  not  only  on  the  information  architecture  derived  from 
the  business  information  but  also  on  current  computer 
systems . 

After  the  team  has  examined  all  the  business  and  IS 
information,  it  is  necessary  to  get  executive  input.  The 
requirement  for  this  input  is  dictated  by  the  top-down 
approach  of  BSP.  The  executive  perspective  is  gained  by 
conducting  interviews  with  personnel  from  the  top  levels  of 
management.  These  interviews  serve  to  validate  the 
processes,  data  classes,  organization,  and  their  interrela¬ 
tionships.  They  help  to  clarify  the  future  direction  of  the 
business  and  its  impact  on  information  requirements.  They 
also  should  identify  and  document  the  business  problems  so 
that  they  may  be  related  to  business  processes  and  data 
classes . 

At  this  stage  the  fact  gathering  is  complete.  Now  it  is 
time  to  arrange  the  facts,  analyze  them  and  draw  conclu¬ 
sions.  Architecture  priorities  can  then  be  determined. 

In  addition  to  determining  information  architecture  and 
setting  application  priorities,  BSP  also  stresses  a  need  to 
ensure  that  the  information  resource  is  managed  properly  to 
support  the  functional  needs  of  the  business.  This 
includes:  seeing  that  the  information  architecture  is 
implemented  in  an  orderly  fashion;  consistent  attention  to 
the  effectiveness  of  information  systems;  that  the  respon¬ 
siveness  of  information  processing  is  assured;  and  that  a 
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viable  information  resource  plan  exists.  "The  basic  premise 
of  information  resource  management  is  the  ability  to  make 
information  available  to  whomever  needs  it  when  and  where  it 
is  needed."  [Ref.  10:p.  69] 

The  BSP  study  team  evaluates  the  information  resource 
management  environment  and  recommends  any  changes  necessary 
to  keep  it  in  consonance  with  these  objectives.  Some  of 
these  issues  were  addressed  in  Chapter  II.  In  addition  to 
those  comments  (of  Chapter  II) ,  a  further  recommendation  of 
a  BSP  study  for  the  Naval  Reserve  may  be  to  form  a  steering 
committee  from  the  functional  groups  of  the  enterprise  to 
oversee  the  information  resource  organization.  If  properly 
implemented,  this  committee  could  be  instrumental  in 
changing  the  perspective  of  the  organization  in  regard  to 
the  proper  role  of  information  resource  management.  In 
focusing  on  the  information  resource  management  functions  of 
the  organization,  BSP  tries  to  ensure  that  the  study  will  be 
more  than  just  an  isolated  inconsequential  occurrence;  but 
that  it  would  be  a  cornerstone  of  a  dynamic,  responsive,  and 
effective  information  resource  organization. 

G .  SUMMARY 

This  chapter  explored  how  well  the  BSP  methodology  would 
fit  the  Naval  Reserve  organization.  This  cursory  examina¬ 
tion  showed  that  not  only  would  it  fit  but  that  it  would 
also  go  a  long  way  toward  resolving  some  of  the  major  prob¬ 
lems  of  information  resource  management  and  planning  that 


were  discussed  in  Chapters  XI  and  III.  A  partial  analysis 
of  business  processes  and  data  classes  highlighted  the  need 
for  the  integration  of  RTSS  and  RESFMS,  the  two  major 
information  systems  of  the  Naval  Reserve.  The  bottom  line 
of  this  chapter  is  that  BSP  is  a  structured  and  comprehen¬ 
sive  planning  methodology  that  would  prove  to  be  very 
beneficial  if  properly  applied  to  the  Naval  Reserve 
organization. 
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V.  CONCLUSIONS 


The  Naval  Reserve  is  a  complex  and  geographically  dis¬ 
persed  organization,  the  effective  management  of  which  is  a 
non-trivial  problem.  It  is  an  organization  rich  in  informa¬ 
tion  but  poor  in  the  management  of  that  information.  Effec¬ 
tive  information  resource  management  is  a  pivotal 
prerequisite  for  the  successful  administration  of  that 
organization.  A  task  which  is  further  complicated  by  the 
nature  and  extent  of  external  information  interfaces. 
Information  systems  in  the  Naval  Reserve  are  dependent  on 
various  data  that  are  owned  and  defined  by  external 
organizations . 

Information  systems  are  becoming  increasingly  critical 
to  the  management  and  day-to-day  operations  of  the  Naval 
Reserve.  It  is  critical  that  their  development  be  as  a 
result  of  careful  and  comprehensive  strategic  IS  planning. 
Many  of  the  shortcomings  of  the  present  information  systems 
can  be  attributed  to  ineffective  long-range  planning.  The 
critical  nature  of  current  and  future  systems  demands 
effective  IS  planning.  Unfortunately,  the  planning  environ¬ 
ment  of  the  organization  is  short-term  crisis  oriented.  The 
organizational  culture  is  contrary  to  any  kind  of  strategic 
thinking.  This  is  the  major  problem  of  the  Naval  Reserve; 
one  which  no  planning  methodology,  by  itself,  can  solve. 
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Some  fundamental  conceptual  changes  need  to  take  place 
within  the  organization  in  order  to  facilitate,  not  only 
more  effective  information  resource  management,  but  also 
more  effective  overall  management. 

In  determining  the  suitability  of  BSP  for  strategic  IS 


planning,  several 

salient  issues 

must 

be 

considered . 

The 

most  important  of 

these  is  how 

well 

it 

conforms  to 

the 

planning  culture  and  other  important  environmental  organiza¬ 
tional  factors.  BSP,  and  all  that  it  stands  for,  is  an 
anathema  to  the  organizational  culture  of  the  Naval  Reserve. 
There  would  have  to  be  a  substantive  change  in  the  percep¬ 
tion  and  implementation  of  planning  activities  in  the 
organization  before  a  BSP  study  could  be  of  any  real 
benefit.  At  this  point  it  would  probably  be  little  more 
than  an  academic  exercise  with  insignificant  organizational 
impact.  It  may,  however,  be  more  palatable  than  a  blatant 
call  for  strategic  planning  because  it  does  offer  some 
short-term  benefits  in  determining  architecture  priorities. 

A  related  issue  is  the  extent  to  which  BSP  would  fit 
into  the  Navy's  strategic  IS  planning  process.  Just  as 
hardware  and  software  compatibility  is  important  in  com¬ 
puter  to  computer  communications,  so  too  is  planning 
methodology  compatibility  important  between  levels  of  the 
same  organization.  Although  it  is  not  strictly  compatible 
with  the  planning  methodology  mandated  by  OP-16,  it  is  not 
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incompatible.  It  also  seems  to  be  more  useful  than  that 
still  evolving  methodology. 

In  BSP,  the  validation  of  the  study  is  a  product  of 
interviews  with  top-level  management.  This  presupposes  that 
these  managers  have  a  far-sighted  and  undistorted 
perspective  of  the  organization  and  a  thorough  understanding 
of  its  functions  and  problems.  This  could  prove  to  be  a 
dangerous  assumption  in  the  case  of  the  Naval  Reserve.  The 
question  is  whether  these  managers  have  a  sufficient  knowl¬ 
edge  of  the  functions  and  problems  of  the  lower  echelons  of 
the  organization.  A  related  question  is  whether  the  study 
would  get  adequate  input  from  these  lower  echelons.  Since 
top-level  managers  may  not  fully  appreciate  the  needs  of  the 
entire  organization,  it  is  imperative  that  the  study  team 
thoroughly  examine  the  entire  organization.  They  could  not 
complete  the  study  without  leaving  New  Orleans.  They_would 
need  to  travel  to  a  variety  of  lower  echelon  commands  in 
order  to  get  a  true  picture  of  the  organization. 

BSP  could  be  a  principal  component  of  a  viable  planning 
process.  It  is  not,  however,  an  easy  solution  for  the 
institutional  neglect  of  strategic  planning  activities. 
Although  a  BSP  study  could  offer  significant  benefits,  it  is 
still  just  a  tool  that,  if  used  improperly  or  in  the  wrong 
environment,  could  do  little  for  the  organization.  BSP  can 
provide  a  comprehensive  methodology  for  understanding  the 
processes  of  an  organization  in  terms  of  its  information 
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